Release 10.1A: OpenEdge Development:
ProDataSets

Controlling the filling of each table

You can issue a FILL on a ProDataSet or a buffer any number of times. You might do this to load data from multiple Data-Sources into a single ProDataSet, for example, which you could do by successively attaching different Data-Sources to the ProDataSet member buffer. Or you could modify the Data-Source query if you needed multiple successive sets of selection criteria to be used to populate all the data needed. Whether this could result in duplicate rows or other problems is determined by setting an attribute called FILL-MODE.

A ProDataSet buffer has a FILL-MODE attribute that can be set to one of several character values:

EMPTY — If there is any data in the table it is emptied before the fill begins.
NO-FILL — This means that the table should not be filled at all on a FILL method because it has already been filled on a previous operation, or it will be filled separately. This might typically be used when one or more data tables are filled once with static or relatively static data that does not change when other data changes; for example, a list of codes that remains constant even as the rest of the ProDataSet is being reused and refilled for different Orders and their related records. If a NO-FILL data table is encountered in the course of a fill that is initiated at a higher level, then that table is not touched, and any relations to child buffers are not traversed, so the FILL effectively stops on that branch of the relation hierarchy. If you issue a FILL directly on a buffer marked NO-FILL, no error results, and no data is loaded into that buffer’s temp-table, beyond what might already be there.
APPEND — A FILL on a buffer whose FILL-MODE is APPEND adds records in addition to anything that’s already there, without doing any record comparisons. If this creates duplicate records that violate a unique index constraint on the temp-table, errors will result and the developer must cope with them. This mode is appropriate when you are implementing some form of batching, when a number of rows are added to a table on one FILL and then the following set on another FILL. However, keep in mind that MERGE mode is nearly as efficient as APPEND mode, so generally you should use the APPEND mode only when you want to be notified with a message about duplicates that occur rather than having them skipped without notification.
MERGE — MERGE is the default FILL-MODE. This mode tells Progress to check for records that are already in the temp-table, based on the table’s unique index, and otherwise add new records to the table. This assures that there are no duplicates. Note that MERGE mode requires that there is a unique primary index using the KEYS fields on the buffer’s temp-table. Progress simply allows the standard database support code to attempt to add each new record to the temp-table. If this fails because of a duplicate key violation in a unique index for the temp-table, that error is suppressed. The cost to this is minimal. Also, in MERGE mode, if a record with the same key is found, it is not replaced. Thus, MERGE cannot be used to refresh records already in a ProDataSet, but only to make it possible to fill a ProDataSet in such a way that the same record might be encountered twice without error or duplication. If you need to refresh records in a ProDataSet table, you can set the table’s FILL-MODE to EMPTY, or you can delete all records or selected records you need to refresh before doing the FILL.
REPLACE — If REPLACE is set, Progress checks each row being filled to see if it is already in the ProDataSet temp-table, based on the temp-table’s unique primary index. If a row with the same key values is already present, its field values are replaced by the field values from the database. If it is not already there, it is created in the temp-table. This FILL-MODE can be useful in situations where a row coming from the database may or may not be a duplicate of a row already in the ProDataSet. If the application cannot know which rows may have different values from the current values, it is not feasible to pre-delete the old row(s) reliably before doing a FILL that brings in new values. Keep in mind that this option is significantly more expensive than using APPEND or MERGE modes, and therefore you should use it only in situations where it is needed.